New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
task -set blend tolerance default based on machine units #1853
Conversation
A very common newbee complaint is huge corner rounding. This is caused by linuxcnc setting the default blend tolerance to maximum. Now we set it to a (seemingly) reasonable default depending if the machine is metric or inch.
This change cause tests in the test suite to fail. To see the errors yourself, run 'scripts/runtests tests/' after a local build. I guess, either the tests need to be modified, or the change need to be disabled by default. |
Is there anything against having an even value if the units are mm? So 0.01 instead of 0.0254. |
[Hans]
Is there anything against having an even value if the units are mm? So
0.01 instead of 0.0254.
I guess the idea was to use the same value for both, and 0.001" is
0.0254mm. I guess the real question is what kind of blend tolerance do
we want to use by default? If we want 0.01mm, the inch value should
probably be 0.0004", not 0.001".
My gut feeling is that 0.03mm is probably within reasonable tolerance of
hobbyinst machines, while 0.01 might be a bit tight, but I have no good
reference to point at for this opinion.
Anyone know what the competitors are using as their default tolerance?
…--
Happy hacking
Petter Reinholdtsen
|
Yes I forgot to run the tests locally. I will fix the tests soon. |
The question is if it has to be equivalent. A value like 0.0254 as precision makes not much sense when not knowing that its derived from inches. Furthermore I think 0.01 is also a good value for hobby machines as it is only the reference value. Position error has to be added to that. |
You think metric should be 3 times tighter then imperial by default? In reality the number should be small enough that it doesn't matter if it's an oddish number. |
This will really change the performance of linuxcnc as far as constant
velocity goes..
.005" or .2mm would be my thought. .0001" is going to act almost like
exact stop mode.
…On Wed, Jul 20, 2022 at 8:11 AM c-morley ***@***.***> wrote:
You think metric should be 3 times tighter then imperial by default?
It may even be that .0001 and .00254 would be useable - I just found .001
(inch) in the forums.
In reality the number should be small enough that it doesn't matter if
it's an oddish number.
and if it does matter then it should be set by the gcode.
—
Reply to this email directly, view it on GitHub
<#1853 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEHRGQRPO74HSNX6MRX2GCDVU73I5ANCNFSM54CHNQXA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
or .1mm .004"
…On Wed, Jul 20, 2022 at 8:20 AM Sam Sokolik ***@***.***> wrote:
This will really change the performance of linuxcnc as far as constant
velocity goes..
.005" or .2mm would be my thought. .0001" is going to act almost like
exact stop mode.
On Wed, Jul 20, 2022 at 8:11 AM c-morley ***@***.***> wrote:
> You think metric should be 3 times tighter then imperial by default?
> It may even be that .0001 and .00254 would be useable - I just found .001
> (inch) in the forums.
>
> In reality the number should be small enough that it doesn't matter if
> it's an oddish number.
> and if it does matter then it should be set by the gcode.
>
> —
> Reply to this email directly, view it on GitHub
> <#1853 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AEHRGQRPO74HSNX6MRX2GCDVU73I5ANCNFSM54CHNQXA>
> .
> You are receiving this because you are subscribed to this thread.Message
> ID: ***@***.***>
>
|
From my reading of the forum, it was suggested that a very small setting was still suffient to get reasonable corner speed. Have you done real world testing? |
I did a ton of trajectory planner testing a long time ago.. ;) Maybe it
isn't as bad as I remember. I just ran tux with a blend of .1mm and .01mm
and the time changed from 1:05 to 1:10 ish..
sam
…On Wed, Jul 20, 2022 at 9:03 AM c-morley ***@***.***> wrote:
From my reading of the forum, it was suggested that a very small setting
was still suffient to get reasonable corner speed. Have you done real world
testing?
To be clear i am definitely preferring path following to speed as a
default.
—
Reply to this email directly, view it on GitHub
<#1853 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEHRGQURUXM3DK7ECOJTMX3VVABMBANCNFSM54CHNQXA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
I Remember u embarrassing Mach 3 :) could u try your test with .0001 setting and see the time difference? |
Or sorry u did .01 mm ok I think that tells us what we need. Thanks |
I will say - most machines - you won't notice .001" path deviation... I
would not go too far..
…On Wed, Jul 20, 2022 at 11:54 AM c-morley ***@***.***> wrote:
Or sorry u did .01 mm ok I think that tells us what we need. Thanks
—
Reply to this email directly, view it on GitHub
<#1853 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEHRGQT4MONZ6XBPOMXS7H3VVAVLVANCNFSM54CHNQXA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
How did you do this testing? Can it be scripted and perhaps added to the tests/ collection? |
src/emc/task/emccanon.cc
Outdated
if (canon.lengthUnits == CANON_UNITS_INCHES) { | ||
SET_MOTION_CONTROL_MODE(CANON_CONTINUOUS, .001); | ||
} else { | ||
SET_MOTION_CONTROL_MODE(CANON_CONTINUOUS, .0254); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps the code intent is expressed more clearly if you use something like .001 * MM_PER_INCH instead of .0254? The compiler will end up with the same value, so there will be no speed impact, but it will be more obvious that the intent is to use the same tolerance independent of units.
Based on the updated g0 test in <URL: #1859 >, I
wrote a test script to run a simple 90 degree path and timed how
different tolerances affected the run time in the simulator:
Operation with tolerance 0.1 took 20 seconds
Operation with tolerance 1 took 20 seconds
Operation with tolerance 0.01 took 20 seconds
Operation with tolerance 0.001 took 20 seconds
Operation with tolerance 0 took 20 seconds
A bit surprised there is no detectable time difference. Suspect I might
be doing something wrong.
These are the changes I did to the g0 test to run G1 with different G64
P values instead of using G0. I am not sure if this is a good way to
test this, but hope it can inspire to create a more sensible test for
this.
diff -ur tests/motion/g0/motion-test.ini tests/motion/g1-tolerance/motion-test.ini
--- tests/motion/g0/motion-test.ini 2022-07-14 23:53:04.436565661 +0200
+++ tests/motion/g1-tolerance/motion-test.ini 2022-07-22 11:46:47.682429732 +0200
@@ -66,8 +66,8 @@
JOINTS = 3
[AXIS_X]
-MIN_LIMIT = -40.0
-MAX_LIMIT = 40.0
+MIN_LIMIT = -400.0
+MAX_LIMIT = 400.0
MAX_VELOCITY = 4
MAX_ACCELERATION = 100.0
@@ -79,8 +79,8 @@
BACKLASH = 0.000
INPUT_SCALE = 4000
OUTPUT_SCALE = 1.000
-MIN_LIMIT = -40.0
-MAX_LIMIT = 40.0
+MIN_LIMIT = -400.0
+MAX_LIMIT = 400.0
FERROR = 0.050
MIN_FERROR = 0.010
HOME_OFFSET = 0.0
@@ -92,8 +92,8 @@
# Second axis
[AXIS_Y]
-MIN_LIMIT = -40.0
-MAX_LIMIT = 40.0
+MIN_LIMIT = -400.0
+MAX_LIMIT = 400.0
MAX_VELOCITY = 4
MAX_ACCELERATION = 100.0
@@ -105,8 +105,8 @@
BACKLASH = 0.000
INPUT_SCALE = 4000
OUTPUT_SCALE = 1.000
-MIN_LIMIT = -40.0
-MAX_LIMIT = 40.0
+MIN_LIMIT = -400.0
+MAX_LIMIT = 400.0
FERROR = 0.050
MIN_FERROR = 0.010
HOME_OFFSET = 0.0
@@ -118,8 +118,8 @@
# Third axis
[AXIS_Z]
-MIN_LIMIT = -4.0
-MAX_LIMIT = 4.0
+MIN_LIMIT = -40.0
+MAX_LIMIT = 40.0
MAX_VELOCITY = 4
MAX_ACCELERATION = 100.0
@@ -131,8 +131,8 @@
BACKLASH = 0.000
INPUT_SCALE = 4000
OUTPUT_SCALE = 1.000
-MIN_LIMIT = -4.0
-MAX_LIMIT = 4.0
+MIN_LIMIT = -40.0
+MAX_LIMIT = 40.0
FERROR = 0.050
MIN_FERROR = 0.010
HOME_OFFSET = 1.0
Only in tests/motion/g1-tolerance/: motion-test.ini.~1~
diff -ur tests/motion/g0/test.sh tests/motion/g1-tolerance/test.sh
--- tests/motion/g0/test.sh 2022-07-22 11:18:35.579823482 +0200
+++ tests/motion/g1-tolerance/test.sh 2022-07-22 23:15:10.413323669 +0200
@@ -6,7 +6,7 @@
wait_for_pin() {
pin="$1"
value="$2"
- maxwait=10 # seconds
+ maxwait=20 # seconds
while [ 0 -lt $maxwait ] \
&& [ "$value" != "$(halcmd -s show pin $pin | awk '{print $4}')" ]; do
sleep 1
@@ -19,49 +19,64 @@
exit 1
fi
}
+runtest() {
+ tolerance=$1
…-linuxcnc motion-test.ini &
-linuxcncpid=$!
+ linuxcnc motion-test.ini &
+ linuxcncpid=$!
-wait_for_pin motion.in-position TRUE
+ wait_for_pin motion.in-position TRUE
-echo starting to capture data
-halsampler -t >| result.halsamples &
-samplerpid=$!
+ echo starting to capture data
+ halsampler -t >| result.halsamples &
+ samplerpid=$!
+
+ start=$(date +%s)
+ (
+ echo hello EMC mt 1.0
+ echo set enable EMCTOO
+
+ echo set mode manual
+ echo set estop off
+ echo set machine on
+
+ echo set home 0
+ echo set home 1
+ echo set home 2
+
+ # Wait for homing to complete
+ wait_for_pin motion.is-all-homed TRUE
+
+ echo set mode mdi
+ echo set mdi F100
+ echo set mdi G64 P$tolerance
+ echo set mdi G1 X0 Y0
+ echo set mdi G1 X10 Y10
+ echo set mdi G1 X20 Y0
+
+ # Wait for movement to complete
+ wait_for_pin joint.0.pos-fb 20
+ wait_for_pin joint.0.in-position TRUE
+ wait_for_pin joint.1.in-position TRUE
+
+ echo shutdown
+ ) | nc localhost 5007
+ end=$(date +%s)
+
+ echo "Operation with tolerance $tolerance took $(($end - $start)) seconds"
+
+ kill $samplerpid
+ wait $samplerpid
+ echo finished capturing data
-(
- echo hello EMC mt 1.0
- echo set enable EMCTOO
-
- echo set mode manual
- echo set estop off
- echo set machine on
-
- echo set home 0
- echo set home 1
- echo set home 2
-
- # Wait for homing to complete
- wait_for_pin motion.is-all-homed TRUE
-
- echo set mode mdi
- dist=1
- echo set mdi g0x$dist
-
- # Wait for movement to complete
- wait_for_pin joint.0.pos-fb $dist
- wait_for_pin joint.0.in-position TRUE
- wait_for_pin joint.1.in-position TRUE
-
- echo shutdown
-) | nc localhost 5007
-
-kill $samplerpid
-wait $samplerpid
-echo finished capturing data
+ # wait for linuxcnc to finish
+ wait $linuxcncpid
+}
-# wait for linuxcnc to finish
-wait $linuxcncpid
+runtest 1
+runtest 0.1
+runtest 0.01
+runtest 0.001
+runtest 0
exit 0
-
--
Happy hacking
Petter Reinholdtsen
|
the acceleration of 100 is quite high.... also - am I seeing the test
correctly?
+ echo set mode mdi
+ echo set mdi F100
+ echo set mdi G64 P$tolerance
+ echo set mdi G1 X0 Y0
+ echo set mdi G1 X10 Y10
+ echo set mdi G1 X20 Y0
A - I don't know if mdi moves are blended
B - even if it did - there are only 2 or 3 corners so not much 'blending'
sa,
…On Fri, Jul 22, 2022 at 4:25 PM petterreinholdtsen ***@***.***> wrote:
Based on the updated g0 test in <URL:
#1859 >, I
wrote a test script to run a simple 90 degree path and timed how
different tolerances affected the run time in the simulator:
Operation with tolerance 0.1 took 20 seconds
Operation with tolerance 1 took 20 seconds
Operation with tolerance 0.01 took 20 seconds
Operation with tolerance 0.001 took 20 seconds
Operation with tolerance 0 took 20 seconds
A bit surprised there is no detectable time difference. Suspect I might
be doing something wrong.
These are the changes I did to the g0 test to run G1 with different G64
P values instead of using G0. I am not sure if this is a good way to
test this, but hope it can inspire to create a more sensible test for
this.
diff -ur tests/motion/g0/motion-test.ini
tests/motion/g1-tolerance/motion-test.ini
--- tests/motion/g0/motion-test.ini 2022-07-14 23:53:04.436565661 +0200
+++ tests/motion/g1-tolerance/motion-test.ini 2022-07-22
11:46:47.682429732 +0200
@@ -66,8 +66,8 @@
JOINTS = 3
[AXIS_X]
-MIN_LIMIT = -40.0
-MAX_LIMIT = 40.0
+MIN_LIMIT = -400.0
+MAX_LIMIT = 400.0
MAX_VELOCITY = 4
MAX_ACCELERATION = 100.0
@@ -79,8 +79,8 @@
BACKLASH = 0.000
INPUT_SCALE = 4000
OUTPUT_SCALE = 1.000
-MIN_LIMIT = -40.0
-MAX_LIMIT = 40.0
+MIN_LIMIT = -400.0
+MAX_LIMIT = 400.0
FERROR = 0.050
MIN_FERROR = 0.010
HOME_OFFSET = 0.0
@@ -92,8 +92,8 @@
# Second axis
[AXIS_Y]
-MIN_LIMIT = -40.0
-MAX_LIMIT = 40.0
+MIN_LIMIT = -400.0
+MAX_LIMIT = 400.0
MAX_VELOCITY = 4
MAX_ACCELERATION = 100.0
@@ -105,8 +105,8 @@
BACKLASH = 0.000
INPUT_SCALE = 4000
OUTPUT_SCALE = 1.000
-MIN_LIMIT = -40.0
-MAX_LIMIT = 40.0
+MIN_LIMIT = -400.0
+MAX_LIMIT = 400.0
FERROR = 0.050
MIN_FERROR = 0.010
HOME_OFFSET = 0.0
@@ -118,8 +118,8 @@
# Third axis
[AXIS_Z]
-MIN_LIMIT = -4.0
-MAX_LIMIT = 4.0
+MIN_LIMIT = -40.0
+MAX_LIMIT = 40.0
MAX_VELOCITY = 4
MAX_ACCELERATION = 100.0
@@ -131,8 +131,8 @@
BACKLASH = 0.000
INPUT_SCALE = 4000
OUTPUT_SCALE = 1.000
-MIN_LIMIT = -4.0
-MAX_LIMIT = 4.0
+MIN_LIMIT = -40.0
+MAX_LIMIT = 40.0
FERROR = 0.050
MIN_FERROR = 0.010
HOME_OFFSET = 1.0
Only in tests/motion/g1-tolerance/: motion-test.ini.~1~
diff -ur tests/motion/g0/test.sh tests/motion/g1-tolerance/test.sh
--- tests/motion/g0/test.sh 2022-07-22 11:18:35.579823482 +0200
+++ tests/motion/g1-tolerance/test.sh 2022-07-22 23:15:10.413323669 +0200
@@ -6,7 +6,7 @@
wait_for_pin() {
pin="$1"
value="$2"
- maxwait=10 # seconds
+ maxwait=20 # seconds
while [ 0 -lt $maxwait ] \
&& [ "$value" != "$(halcmd -s show pin $pin | awk '{print $4}')" ]; do
sleep 1
@@ -19,49 +19,64 @@
exit 1
fi
}
+runtest() {
+ tolerance=$1
-linuxcnc motion-test.ini &
-linuxcncpid=$!
+ linuxcnc motion-test.ini &
+ linuxcncpid=$!
-wait_for_pin motion.in-position TRUE
+ wait_for_pin motion.in-position TRUE
-echo starting to capture data
-halsampler -t >| result.halsamples &
-samplerpid=$!
+ echo starting to capture data
+ halsampler -t >| result.halsamples &
+ samplerpid=$!
+
+ start=$(date +%s)
+ (
+ echo hello EMC mt 1.0
+ echo set enable EMCTOO
+
+ echo set mode manual
+ echo set estop off
+ echo set machine on
+
+ echo set home 0
+ echo set home 1
+ echo set home 2
+
+ # Wait for homing to complete
+ wait_for_pin motion.is-all-homed TRUE
+
+ echo set mode mdi
+ echo set mdi F100
+ echo set mdi G64 P$tolerance
+ echo set mdi G1 X0 Y0
+ echo set mdi G1 X10 Y10
+ echo set mdi G1 X20 Y0
+
+ # Wait for movement to complete
+ wait_for_pin joint.0.pos-fb 20
+ wait_for_pin joint.0.in-position TRUE
+ wait_for_pin joint.1.in-position TRUE
+
+ echo shutdown
+ ) | nc localhost 5007
+ end=$(date +%s)
+
+ echo "Operation with tolerance $tolerance took $(($end - $start))
seconds"
+
+ kill $samplerpid
+ wait $samplerpid
+ echo finished capturing data
-(
- echo hello EMC mt 1.0
- echo set enable EMCTOO
-
- echo set mode manual
- echo set estop off
- echo set machine on
-
- echo set home 0
- echo set home 1
- echo set home 2
-
- # Wait for homing to complete
- wait_for_pin motion.is-all-homed TRUE
-
- echo set mode mdi
- dist=1
- echo set mdi g0x$dist
-
- # Wait for movement to complete
- wait_for_pin joint.0.pos-fb $dist
- wait_for_pin joint.0.in-position TRUE
- wait_for_pin joint.1.in-position TRUE
-
- echo shutdown
-) | nc localhost 5007
-
-kill $samplerpid
-wait $samplerpid
-echo finished capturing data
+ # wait for linuxcnc to finish
+ wait $linuxcncpid
+}
-# wait for linuxcnc to finish
-wait $linuxcncpid
+runtest 1
+runtest 0.1
+runtest 0.01
+runtest 0.001
+runtest 0
exit 0
-
--
Happy hacking
Petter Reinholdtsen
—
Reply to this email directly, view it on GitHub
<#1853 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEHRGQUQM2FIQNPWEO2SCG3VVMGVNANCNFSM54CHNQXA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
[samcoinc]
the acceleration of 100 is quite high.... also - am I seeing the test
correctly?
This is the test, yes:
+ echo set mode mdi
+ echo set mdi F100
+ echo set mdi G64 P$tolerance
+ echo set mdi G1 X0 Y0
+ echo set mdi G1 X10 Y10
+ echo set mdi G1 X20 Y0
Perhaps you can come up with a better test?
A - I don't know if mdi moves are blended
B - even if it did - there are only 2 or 3 corners so not much
'blending'
I do not know if MDI moves are blended either, nor do I know how to test
using non-MDI mode. How can we tell if MDI instructions are blended?
…--
Happy hacking
Petter Reinholdtsen
|
Operation with tolerance 0.1 took 20 seconds try it compared to g61 A program with many short segments would show blending better (more time in acceleration phase rather then cruise phase) |
[c-morley]
A program with many short segments would show blending better (more
time in acceleration phase rather then cruise phase)
Your test program should show the path deviation though.
I hope my example can inspire someone who know G-code and LinuxCNC
better than me to come up with a test that demonstrate the effect of
changing the tolerance. I am not competent to do so myself.
…--
Happy hacking
Petter Reinholdtsen
|
Le sam. 23 juil. 2022 à 07:31, petterreinholdtsen ***@***.***>
a écrit :
[c-morley]
> A program with many short segments would show blending better (more
> time in acceleration phase rather then cruise phase)
> Your test program should show the path deviation though.
Could a kind of routine plotting time and path deviation provided a range
of blending tolerances be a machine tuning tool?
|
it's more of a program tuning code. Machine can only do what the hardware will let it. |
thanks for your help to make this better. merged |
I've unsuccessfully tried to trigger a slowdown using smaller and
smaller G64 P# values. Is the fear of slowing down the machine
overrated, or is the test code not correctly structured?
--
Happy hacking
Petter Reinholdtsen
|
It will probably depend on the accelleration limits of the machine. Were you testing in a simulator? What were the acceleration limits? |
Have you been looking for path deviation as well as speed up? |
A very common newbee complaint is huge corner rounding.
This is caused by linuxcnc setting the default blend tolerance to maximum.
Now we set it to a (seemingly) reasonable default depending if the machine
is metric or inch.